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(54) Execution of service control requests in a single service control point 



(57) The invention provides with a method for sim- 
plifying call control to a plurality of call models and de- 
velopment of an SSP. An SCP call control system ac- 
cording to the invention is operable to store parameters 



in an SCP call message depending on its structural in- 
formation and access the parameters by using the struc- 
tural information regardless a structure of the message, 
when the message is received. 
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Description 

BACKGROUND OF THE INVENTION: • 

[0001] This invention relates to a call control system 
for use in a SCP (Service Control Point) included in an 
intelligent network (which will often be abbreviated to an 
IN). 

[0002] Nowadays, consideration has been directed 
about making a network highly intelligent in order to re- 
spond to a wide variety of requirements for communica- 
tions. Such consideration might be very important more 
and more in connection with an advanced communica- 
tion network as well as a broadband network and a per- 
sonalized network. Heretofore, an IN intelligent Net- 
work) has been proposed so as to make a network high- 
ly intelligent. 

[0003] In such an IN, a plurality of intelligent periph- 
erals (will be abbreviated to IP) and a plurality of vender 
feature nodes ( VFN) are used as terminal devices. Each 
of the terminal devices is connected to a service control 
point (will be abbreviated to SCP) through, a service 
switching point (will be simply called SSP) which is op- 
erable in a manner similar to a conventional exchange. 
Each of the SCPs is managed by a service management 
system (SMS) which has a database. 
[0004] In a conventional IN, high intelligence is not 
given to each SSP but is concentrated into each SCP 
to which the SSP is connected by transmitting a service 
control request message from the SSP to the SCR The 
SCP executes call control operation in accordance with 
a service control request message to provide service to 
a user connected through the SSP to each terminal de- 
vice. The call control operation is peculiar to or deter- 
mined by the service control request message. 
[000S] From this fact, it is understood in the conven- 
tional IN that the SCP should be designed to respond to 
the service control request message and can provide 
the service to each user as long as the service control 
request message has the format determined for the 
SCP. 

[0006] Herein, the SSP may not be always connected 
to the terminal devices which have the service control 
request message of the same format but may be con- 
nected to a plurality of the terminal devices which are 
different in species from one another. In this case, the 
SCP is supplied from each of the terminal devices 
through the SSP with a service control request message 
of a format which is different from one another to specify 
the species of the terminal devices. 
[0007] In addition, a new model of the SSP may be 
partially substituted into the IN for an old model of the 
SSP and may be connected to the SCP in common to 
the old model SSP This results in coexistence of the old 
and the new model SSPs in the conventional IN. 
[0008] Under the circumstances : each SCP in the 
conventional IN can neither respond to the different 
service control request messages nor can cope with the 



1 coexistence of the old and the new model SSPs. 

SUMMARY OF THE INVENTION: 

$ [0009] It is an object of this invention to provide an 
intelligent network (IN) which can conveniently respond 
to a plurality of service control request messages differ- 
ent from each other 

[0010] It is another object of this invention to provide 
10 an intelligent network (IN) of the type described, which 
can allow both old and new model SSPs to be connected 
to a common SCR 

[0011] It is yet another object of this invention to pro- 
vide an SCP which is applicable to an IN of the type de- 
*s scribed. 

[0012] It is still another object of this invention to pro- 
vide a method of controlling a plurality of service control 
request messages in a single SCP used in the IN. 
[0013] An SCP call control system according to the 

20 invention comprises at least one SCP and a plurality of 
SSPs which are configured to send service control re- 
quest messages each including an address of source. 
The SCP comprises a call model determining unit which 
extracts an address of a source from the received call 

25 control request message and which determines a call 
model corresponding to the address of source, a call 
model switching unit which switches to a resource ad- 
dress of the determined call model; a resource manag- 
ing unit which manages a resource of a currently used 

30 call model, and a resource accessing unit which allows 
a service logic program actually providing a service to 
access to the switched resource. 

[001 4] According to the invention, plural kinds of serv- 
ice control request messages can be treated in a single 
35 SCP. 

BRIEF DESCRIPTION OF THE DRAWING: 
[0015] 

40 

Fig. 1 shows a block diagram for use in describing 
a conventional intelligent network (IN): 
Fig. .2 shows a block diagram of an IN according to 
a preferred embodiment of this invention so as to 
45 describe call control operation which is executed in 
a service control point (SCP) in the IN; 
Fig. 3 shows a block diagram of a part of the SCP 
illustrated in Fig. 2; 

Fig. 4 shows a block diagram of a resource manag- 
50 ing unit illustrated in Figs. 2 and 3: 

Fig. 5 shows a block diagram for use in describing 
a part of the resource managing unit illustrated in 
Fig. 4; 

Fig. 6 shows a block diagram for use in describing 
55 another part of the resource managing unit illustrat- 
ed in Fig. 4: and 

Fig. 7 shows a flow chart for use in describing op- 
erations of the SCP call control system shown in 
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Fig. 2. 

DESCRIPTION OF THE PREFERRED EMBODIMENT: 

[0016] Referring to Fig. 1, description will be at first 
made about a conventional intelligent network (IN) for a 
better understanding of this invention. The illustrated in- 
telligent network.(IN) has a plurality of terminal devices, 
such as terminal equipment (TE) 5, intelligent peripher- 
als (IP) 6 : and vender feature nodes (VFN) 7, a plurality 
of SSPs 4 connected to the terminal devices, a plurality 
of SCPs 2 connected to the SSPs 4 through a common 
channel signal network of the No. 7 type, and a service 
management system (SMS) 1. Among the terminal de- 
vices, the IP 6 is located at a subscriber site and pro- 
vides an advanced facility to the subscriber while the 
VFN 7 is managed by a vender. 

[0017] The illustrated SSPs 4 (Service Switching 
Point) each correspond to an exchange located in a con- 
ventional network. The SSPs 4, however have not ad- 
vanced intelligence, but the advanced intelligence is 
concentrated into;the SCPs 2. Also, SCPs 2 and SSPs 
4 are connectedythrough a common channel signaling 
network of the No. 7 type (SS7), and commands and 
data are transmitted between the SCPs 2 and SSPs 4 
via the network, u :r. 

[0018] Furthermore, SCPs 2 are provided with some 
centralized databases and respond to requests from the 
SSPs 4. There is an SMS 1 (Service Management Sys- 
tem) at a higher layer than that of the SCPs 2. The SMS 
1 is connected to the SCPs 2 through an x.25 data net- 
work. In the database provided with the SMS 1 , common 
data pertaining to its area is stored. 
[0019] In the above-mentioned system, a variety of 
terminal devices may be connected to each SSP 
[0020] For call control between an SSP and an SCR 
the SSP uses a method dedicated to its own type. As a 
result, a type of SSP is sent as a service control request 
message in a format which is different from another type 
of SSP. The methods are defined as "call model" in this 
specification. 

[0021] In the past, dedicated SCPs are developed for 
each call model. Therefore, it is impossible that a single 
SCP is simultaneously connected to a plurality of SSPs 
each of which uses a call model which is different from 
any call model used by the other SSPs (for example, 
different INAP (intelligent network application protocol)). 
As a result, the SCP can simultaneously execute 
processing for the connected SSPs. If a single SCP is 
connected for plural kinds of call models ; the SCP needs 
to individually start process for each call model and dis- 
tribute the service control request messages according 
to its call model. 

[0022] Referring to Fig. 2, it is shown a block diagram 
representing an embodiment of the invention In Fig. 2, 
an SSP 4 is connected to an SCP 2 through a common 
channel signaling network which is not shown in Fig. 2. 
The SCP 2 is provided with a call model managing unit 



10 and a service logic program 15. 

[0023] The call model managing unit 10 further com- 
prises four kinds of units, that is, a call model determin- 
ing unit 11, a call model switching unit 12, a resource 

5 managing unit 13 : and a resource accessing unit 14. 
Hereinafter, each of the units will be described in detail. 
[0024] The call model determining unit 1 1 determines 
a call model based on a resource address in a service 
control request message. 

w [0025] The call model switching unit 12 provides the 
call model determined by the call model determining unit 

11 to the resource managing unit 1 3. 

[0026] The resource managing unit 13 includes re- 
sources for each call model. The resource includes 

is structure definitions and storage region of service con- 
trol request messages in a call model. 
[0027] In this specification, the structure definitions 
and storage regions of the messages in a call model are 
collectively referred to as a "resource". Also an address 

20 of an area including a set of pointers each of which 
points to the structure definition or storage region is re- 
ferred to as a "resource address". 
[0028] The resource accessing unit 14 allows the 
service logic program 15 to access to the resources in 

25 the resource managing unit 1 3 in the same manner even 
if the call model is changed. Therefore, when the call 
model is changed, it is no need for the service logic pro- 
gram 1 5 to consider its interface with the resource man- 
aging unit 1 3 in accessing to the resources. 

30 [0029] Also, the service logic program 1 5 operates ac- 
cording to information modified by the call model man- 
aging unit 10 based on the service control request mes- 
sage sent from the SSP 4. 

[0030] Referring to Fig. 3, description will be made 
35 about the call model determining unit 11, call model 
switching unit 12, and resource managing unit 13. As 
shown in Fig. 3, the call model determining unit 11 de- 
termines a call model by using a call model determina- 
tion table 20. 

40 [0031] The call model determination table 20 is a da- 
tabase in which each originating address information is 
related to a corresponding call model I D in advance. The 
originating address information may be an identification 
of a terminal device, for example a network address of 

45 the device, which sends a service control request mes- 
sage to the SSP4. Therefore, the call model determining 
unit 11 can search the corresponding call model ID by 
using the originating address information as a key. The 
call model ID is used in the SCP to identiiy a call model. 

50 it is possible to use a point code or a sub system number 
of a signal connection controller of a common channel 
signaling network of No. 7 type as the originating ad- 
dress information. 

[0032] The call model switching unit 1 2 is a database 
55 in which each call model I D is related to a corresponding 
resource address. Therefore, the call model switching 
unit 1 2 can search an intended resource address by us- 
ing the call model ID as a key. A resource is generated 
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for each call model and the resource address is stored 
into the call model management table 21 when the call 
model managing process is initialized. 
[0033] The corresponding resource address can be 
sent to the resource managing unit 1 3 as a resource ad- 
dress of current call model according to the current call 
model ID. Next, the resource in the resource managing 
unit 1 3 can be accessed by using the resource address. 
The resource includes structure definitions and storage 
regions of the messages. As described above, the re- 
source address includes an address of an area including 
a set of pointers each of which points to the structure 
definition or storage region. Therefore, the SCP accord- 
ing to the invention can retrieve the structure definition 
and the storage region, as a result, retrieve the param- 
eters in the message in the same manner by referring 
to the resource in the resource managing unit 13 even 
if different call models of messages are given. 
[0034] Fig. 4 is a block diagram showing the resource 
managing unit 1 3 in more detail The resource managing 
unit 1 3 includes a resource, that is, structure definitions 
and storage regions. As shown in Fig. 4, the structure 
definitions correspond to a parameter definition re- 
source 30 and a message definition resource 31 , and 
the storage regions correspond to a call memory man- 
aging unit 32. Each pointer associated with a resource 
address 22 of the currently used call model (hereinafter 
referred to as "current call model") points to the param- 
eter definition resource 30, the message definition re- 
source 31 , and the call memory managing unit 32. 
[0035] Hereinafter, description will be made about an 
example of switching the resource address according to 
the current call model with respect to Figs. 3 and 4. Now, 
it is assumed that the service logic program 15 refers to 
a resource address 21 in the call model management 
table 12 in Fig 3. 

[0036] The resource address 21 are supplied to the 
resource management unit 1 3 as a resource address 22 
of the current call model. The resource address 22 in- 
cludes three pointers which point to the beginning point 
of the parameter definition resource 30, the message 
resource 31 , and the call memory management unit 32 
for the current call model in Fig 4 ; respectively. 
[0037] It is possible to store the message and read 
the message stored, by using the parameter definition 
resource 30, the message resource 31, and the call 
memory management unit 32. Therefore, when the 
service logic program 15 obtains the addresses of the 
beginnings of the parameter definition resource 30, the 
message resource 31, and the call memory manage- 
ment unit 32 by referring to the pointers, the resultant 
service logic program 15 can access a parameters in 
the message by controlling addresses relative to the ad- 
dresses of the beginnings. 

[0038] Because resource addresses 21 are expected 
to take different values according to the call model, the 
service logic program 15 can access the messages for 
different call models in a similar accessing manner. 



[0039] Fig. 5 is a block diagram showing an internal 
structure of the parameter definition resource 30 and the 
call memory managing unit 32 in more detail. As shown 
in Fig. 5, the call memory managing unit 32 manages a 
5 call memory pool 43 which is a set of a plurality of call 
memories 44. 

[0040] Here, a single call memory 44 is generally as- 
signed to a single service which is achieved by a single 
service logic program 15. The call memory 44 is a con- 

10 stant volume buffer as far as the logic program 1 5 uses 
the whole volume of the call memory 44 as a single area. 
The call memory 44, however, can be used as areas 45 
storing a value of a parameter corresponding to attribute 
data which are defined in a parameter management in- 

15 formation table 42 in the parameter definition resource 
30, by subdividing the call memory 44 into smaller areas 
45. The attribute data in the parameter management in- 
formation table 42 are defined for each parameter and 
can include type, size value, and offset value of the pa- 

20 rameter. 

[0041] Also, to identify an area 45 in the call memory 
44, the offset value is used to show the distance from 
the beginning point of the call memory 44 to the begin- 
ning point of the area 45, and the size value is used to 

25 show the length of the area 45. Furthermore, by desig- 
nating the type, it is possible to define behavior about 
the parameter in the service logic program 15. 
[0042] On the other hand ; it is. possible to use either 
a parameter name table 40 or a parameter ID table 41 

30 for retrieving the attribute data from the parameter man- 
agement information table 42. That is, retrieving with a 
parameter name is mainly employed by the service logic 
program 15 via the resource accessing unit 14. While, 
retrieving with a parameter I D is mainly employed by us- 

35 jng the message definition resource 31 which will de- 
scribed below. 

[0043] Fig. 6 is a block diagram showing the message 
definition resource 31 in more detail. As shown in Fig. 
6 ; the message definition resource 31 includes a mes- 

40 sage table 50 and a parameter table 51. The message 
table 50 includes message names of a service control 
request message which belongs to intended call model 
and pointers associate the message names with corre- 
sponding entries in the parameter table 51 . The param- 

45 eter table 51 includes encode/decode information for 
subdividing the service control request message into in- 
dividual parameters and pointers which associate the 
encode/decode information, that is a list of parameters 
included in each message, with corresponding entries 

50 jn the parameter management information table 42 in 
the parameter definition resource 30. Also, since some 
parameters in the message may have nested structure, 
the pointers in the parameter table 51 may be related to 
the entries in another table 51a shown in Fig. 6. 

55 [0044] In Fig. 6, following the pointers in the tables in 
the message definition resource 31 leads to an entry of 
the parameter management information table 42. 
[0045] An operation of the invention configured as de- 
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scribed above will be described in more detail with re- 
spect to Fig. 7. Fig. 7 is a flow chart showing an opera- 
tion of the SCP call control system shown in Fig. 2. 
[0046] First, at a step 1 01 , the SCP is initialized before 
receiving a service control request message from a us- 
er. Simultaneously, the SCP is supplied with data per- 
taining to possible call models and necessary resources 
are generated to prepare tables for accessing the mes- 
sages, v*:?/ 

[0047] Next, at.a step 102, the SCP uses originating 
address information and a call model determination ta- 
ble 20 to determine a call model ID when it receives a 
service control. request message from an SSP 
[0048] At a step-103, the SCP uses the call model ID 
and a call model management table 12 to determine a 
resource address, and switches a resource address of 
the current call model to the resource address which is 
determined. 

[0049] At a step 1 04, the SCP successively traces or 
follows pointers, from a pointer in the message table 50 
to a pointer in the parameter table 51 to identify entries 
in the parameter.management information table 42 cor- 
responding to parameters in the received service control 
request message*- 

[0050] At a step?1 05, the SCP divides the service con- 
trol request message into parameters according to the 
entries in the parameter management information table 
42. Next, for each?parameter, the SCP obtains informa- 
tion including type, size, and offset value from the cor- 
responding entry in the parameter management infor- 
mation table 42. Then, the SCP stores the value of the 
parameter in an area 45 in the call memory 44 according 
to the information from the parameter management in- 
formation table 42. The offset value is representative of 
a distance from the beginning point of the call memory 
44 to the beginning point of an area 45 in which the value 
of the parameter should be stored. These operations are 
repeated until all the parameters have been stored in 
the call memory 44. 

[0051 ] At a step 1 06, the SCP accesses an actual val- 
ue of a parameter stored in an area 45 by a service logic 
program 15 using a parameter name or an parameter 
ID as a key through a resource accessing unit 14. 
[0052] An embodiment of the invention which is con- 
figured to realize the above structure, will be described 
below in brief. An SCP is connected to two SSPs: one 
of them uses an old call model and the other uses a new 
call model different from the old call model. Now, con- 
sidering the case where each SSP sends a service con- 
trol request message to the SCP independently of each 
other. 

[0053] The SCP can deal with these two SSPs by 
processing each service control request message after 
switching to a resource corresponding to the service 
control request message. For example, an encode/de- 
code information registered in the parameter table 51 
includes tag information of ASN.1 (Abstract Syntax No- 
tation 1) to deal with I NAP (Intelligent Network Applica- 



tion Protocol) messages. 

[0054] Also, a pointer is used to link an entry in a table 
to another entry in another table. Alternatively, another 
method can be realized by linking a common I D included 

5 in both entries. 

[0055] Similarly, to deal with a message having struc- 
ture, the encode information and decode information in- 
clude sizes and offset values. Then the SCP divides a 
message into parameters according to information of 

io the parameter table(s) 51 (51a), finally stores each pa- 
rameter into an area 45 in a call memory 44, at address 
designated by the offset value in the parameter man- 
agement information table 42. 

[0056] As a result, even if the SCP receives a service 
'5 control request message from either of the SSPs, the 
service logic program 15 can obtain an intended value 
of each parameter from the call memory 44 in the same 
manner. 

[0057] For example, it is assumed that provision is 
20 made about a scenario SA for a cell model A and a sce- 
nario SB for another call model B. Herein, the scenario 
means definitions of processing or behavior when a val- 
ue of a parameter in a service control request message 
is given. The scenarios SA and SB may define the same 
25 processing according to values of common items in both 
messages. However, unique scenario which uses an 
item which is not included in the other call model mes- 
sages may be produced. 

[0058] In both cases, an access module, such as a 
30 service logic program 15, achieving the scenario can 
read the parameter in the message by only designating 
a parameter name or a parameter ID, without recogni- 
tion of data type, data size, or offset location of the pa- 
rameter. 

35 [0059] As described above, since the invention can 
select call models according to a source of a service 
control request message, simultaneous connection to 
the SSPs each of which uses a call model different from 
each other is allowable. Therefore, the SCP of the in- 

^o vention can maintain its service even if a call model used 
by an SSP is changed. However, it is noted that the in- 
vention can select the call models by using another ba- 
sis, for example one or more identifiers in the message. 
[0060] Further, since structures of messages and lo- 

45 cations in which parameters should be stored are deter- 
mined in a data driven manner, encoding/decoding of 
the parameters or accessing to the parameters can be 
adjusted according to received service control request 
messages. 

so [0061 ] Therefore, it will be easy to deal with a new call 
model and to modify an existing call model by using the 
invention. 

[0062] While the embodiment of the invention has 
been described with respect to SCP and SSP in an IN, 
55 the embodiment is merely illustrative. For example, it is 
possible that the invention can be applied to the other 
various functional element in various messaging sys- 
tems. 
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[0063] Also, while person skilled in the art may think 
of modification and variation of the invention, it is 
thought that these are all in a spirit of the invention. 



Claims 

1. In an SCP call message control system in an intel- 
ligent network having a plurality of service switching 
points (SSPs 4) each of which uses a call model 
different from each other and having at least one 
service control point (SCP 2), 

the plurality of SSPs are configured to send 
service control request messages each includ- 
ing an address of source, 
the SCP comprising: 

a call model determining means (1 1 ) which 
extracts the address of source from the re- 
ceived call control request message and 
determines a call model corresponding to 
the address of source; 
a call model switching means (12) which 
switches to a resource address of the de- 
termined call model; 

a resource managing means (13) which 
manages a resource of a currently used 
call model; and 

a resource accessing means (14) which al- 
lows a service logic program (15) actually 
providing a service to access to the 
switched resource. 



2. 



3. 



4. 



The system as claimed in claim 1 , wherein the call 
model switching means ( 1 2) comprises a call model 
management table (21 ) in which each call model ID 
is made to correspond to the resource address. 

The system as claimed in claim 1, wherein the re- 
source managing means (13) comprises a param- 
eter definition resource (30) which includes infor- 
mation for managing parameters: a message defi- 
nition resource (31) which includes information for 
encoding/decoding the service control request 
messages, and buffers (32) for storing the contents 
of the parameters. 

A service control unit operable in response to a plu- 
rality of messages which are different in type from 
one another and are produced from originating 
sources., comprising: 



10 



15 



20 



25 



storing means for storing a plurality of defini- 
tions concerned with the plurality of the mes- 
sages: and 

access means responsive to each of the mes- 
sages for accessing to the storing means to 
specify each of the definitions corresponding to 
each of the messages. 

6. The unit as claimed in claim 5, wherein said defini- . 
tion holds the definitions for each type of message 
or message group which includes a plurality of 
types of message, and further comprising: 

switch means which switches the definition ac- 
cording to the type of message or the message 
group. 

7. The unit as claimed in claim 5, wherein said mes- 
sage includes a plurality of parameters, and said 
definition comprising: 

information representing an arrangement of the 
parameters in the message: 
information representing attributes of each pa- 
rameter in the message: and 
information representing storage locations in 
which the parameters in the message are 
stored. 



30 8. 



The system as claimed in claim 1, wherein the call 35 
model determining means (11) comprises a call 
model determination table (20) in which each ad- 
dress of source is made to correspond to a call mod- 
el ID. 



9. 



40 



45 



50 



55 



The unit as claimed in claim 5, said unit being used 
as a service control point in an intelligent network 
which comprises a plurality of service switching 
points for transferring the call control request mes- 
sages to the service control point through a com- 
mon network laid between the service control point 
and the service switching points. 

A method for controlling messages in a service con- 
trol unit operable in response to a plurality of mes- 
sages which are different in type from one another 
and are produced from originating sources, com- 
prising the steps of: 

registering definitions concerned with the plu- 
rality of the messages: 

resolving the message into elements according 
to the definitions and storing the elements into 
storage locations to associate the location with 
the definition; and 

accessing to the elements of the messages by 
using the definition. 



1 0. The method as claimed in claim 9, wherein said def- 
inition holds the definitions for each type of mes- 
sage or message group which includes a plurality 
of types of message, and further comprising the 
step of: 
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switching the definition according to the type of " 
message or the message group. 

11. The method as claimed in claim 9, wherein said 
message includes a plurality of parameters : and s 
said definition comprising: 

information representing an arrangement of the 
parameters in the message: 

information representing attributes of each pa-. ?o 
rameteMn the message; and 
information representing storage locations in 
which the parameters in the message are 
stored. - 

15 

12. The method as claimed in claim 9, said method be- 
ing used in a service control point in an intelligent 
network which comprises a plurality of service 
switching points for transferring the call control re- 
quest messages to the service control point through 20 
a common network laid between the service control 
point and the service switching points. 

13. A computerj.readable medium which stores a pro- 
gram operable in response to a plurality of messag- 25 
es which are different in type from one another and 

are produced from originating sources; said pro- 
gram comprising the steps of: 

registering definitions concerned with the plu- 30 
rality of the messages; 

resolving the message into elements according 
to the definitions and storing the elements into 
storage locations to associate the location with 
the definition; and 35 
accessing to the elements of the messages by 
using the definition. 



40 



45 



50 



55 



BNSDOCID: <EP_0912069A2J_> § v 



EP0J912 069A2 



SMS 



S / / I \ 

/ / / i \ 



/ / 



S S P 



I p 



V F N 



S S P 




S S P 













SC P 




S CP 


1 

1 

1 






No. 7 COMMON CHANNEL SIGNALING 
NETWORK 



T E 



(' } 



FIG. 1 
PR ! OR ART 



BNSDOCID: <EP 091 2069 A2_l_> 



EP 0 912 069 A2 



O 



SS P 



^SERVICE CONTROL REQUEST MESSAGE 



5 






CALL MODEL DETERMINING 
MEANS 


1 










CALL MODEL SWITCHING 
MEANS 


1 2 




* 






RESOURCE MANAGING 
MEANS 


^1 3 




t ' 






RESOURCE ACCESSING 
MEANS 


^1 4 




CALL MODEL MANAGING MEANS 



1 0 



SERVICE LOGIC PROGRAM 



1 5 



S C P 



FIG. 2 



BNSDOCIO: <EP 0912069A2J_> 



9 



EP 0 912 069 A2 



X± 



1 1 



CALL MODEL DETERMINATION TABLE 



ORIGINATING ADDRESS 
INFORMATION 



XL 



2 0 



CALL MODEL (0 



CALL MODEL DETERMINING MEANS 



1 2 



CALL MODEL MANAGEMENT TABLE 



RETRIEVE 



CALL MODEL ID 



xL 



2 1 



RESOURCE ADDRESS 



CALL MODEL SWITCHING MEANS 











RESOURCE ADDRESS OF A CURRENT 








CALL MODEL 






RESOURCE MANAGING MEANS 



SWITCH 



t 3 



o 



FIG. 3 



BNSDOCID: <EP 0912069A2_I_> 



10 



EP 0 912 069 A2 



RESOURCE ADDRESS OF A CURRENT 
CALL MODEL 



2 2 



PARAMETER DEFINITION 
RESOURCE 



'3 0 



MESSAGE DEFINITION 
RESOURCE 



3 I 



CALL MEMORY MANAGING 
MEANS 



3 2 



RESOURCE MANAGING MEANS 



FIG. 4 



11 

BNSDOCID: <EP_09.2069A2J_> , . .. J*. i4tt ... . . *^ 



EP0 912 069,A2 



3 0 



PARAMETER NAME TABLE 



PARAMETER NAME 


POINTER 























PARAMETER ID TABLE 



PARAMETER ID 


POINTER 























4 0 



PARAMETER MANAGEMENT 
INFORMATION TABLE 



TYPE. SIZE OFFSET VALUE 



•4 1 



4 2 



PARAMETER DEFINITION RESOURCE 









y 

/ 

/ 

/ 

/ 

/ 

CALL MEMORY POOL / 


/ 

/ 

✓ 


i 
1 






















CALL MEMORY 














































CALL MEMORY MANAGING MEANS 




_j — __ 



43 V 



3 2 

FIG. 5 



12 



EP 0 912 069 A2 



3 I 
_1_ 



MESSAGE TABLE 



MESSAGE NAME 


POINTER 























5 0 



PARAMETER TABLE 



.ENCODE/DECODE 
INFORMATION 


POINTER 


^5 1 































PARAMETER TABLE 



ENCODE/DECODE 
INFORMATION 


POINTER 























7 

5 1 a 



MESSAGE DEFINITION RESOURCE 



3 0 



PARAMETER MANAGEMENT INFORMATION TABLE 



TYPE, SIZE, OFFSET VALUE 



4 2 



PARAMETER DEFINITION 
RESOURCE 



FIG. 6 



13 



BNSOOCID: <EP 091 2069 A2_l_> 



EP 0^12 069 A2 



RESOURCE PREPARATION 



CALL MODEL DETERMINATION 



RESOURCE SWITCHING 



I 0 I 



I 0 2 



1 0 3 



MESSAGE TABLE RETRIEVING 



]~ 1 0 



PARAMETER TABLE RETRIEVING 
AND PARAMETER DIVISION 



PARAMETER ACCESSING 



1 0 5 



1 0 6 



FIG. 7 



14 

BNSDOCID: <EP 0912069A2J_> 



i 



(19) 



3 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



.V 



(12) 



(id EP 0 912 069 A3 

EUROPEAN PATENT APPLICATION 



(88) 


Date of publication A3: 


(51) intci ? H04Q 3/00 




08.03.2000 Bulletin 2000/10 


(43) 


Date of publication A2: 






28.04.1999 Bulletin 1999/17 




(21) 


Application number: 98402643.5 




(22) 


Date of filing: 23.10.1998 




(84) 


Designated Contracting States: 


(72) Inventor: Fuse, Motonari 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 


Minato-ku, Tokyo (JP) 




MC NL PT SE 






Designated Extension States: 


(74) Representative: Signore, Robert et al 




AL LT LV MK RO SI 


c/o SOCIETE DE PROTECTION DES 






INVENTIONS 


(30) 


Priority: 24.10.1997 JP 29213097 


3, rue du Docteur Lanceraux 






75008 Paris (FR) 


(71) 


Applicant:JMEC CORPORATION 






Tokyo (JP) 





(54) Execution of service control requests in a single service control point 



(57) The invention provides with a method for sim- 
plifying call control to a plurality of call models and de- 
velopment of an SSP. An SCP call control system ac- 
cording to the invention is operable to store parameters 



in an SCP call message depending on its structural in- 
formation and access the parameters by using the struc- 
tural information regardless a structure of the message, 
when the message is received. 



CO 
< 

O) 
CD 

o 

CM 

o 

Q_ 

LU 



BNSDOCID: <EP 091 2069 A3 J_> 



SSP 



^SERVICE CONTROL REQUEST MESSAGE 



CALL MODEL DETERMINING 
MEANS 



CALL MODEL SWITCHING 
WEANS 



RESOURCE MANAGING 
MEANS 



RESOURCE ACCESSING 
MEANS 



-1 1 



' I 2 



-1 3 



-1 4 



CALL MODEL MANAGING KEANS 



-I 0 



SERVICE LOGIC PROGRAM 



-I 5 



SCP 



FIG. 2 



Printed by Jouve. 750O1 PARIS (FR) 



EP0912 069 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 98 40 2643 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (lnt.Cl.6> 



EP 0 620 693 A (GPT LIMITED) 
19 October 1994 (1994-10-19) 

* page 1, line 27 - page 2, line 30 * 

DATABASE WPI 

Section EI, Week 199730, 

16 May 1997 (1997-05-16) 

Derwent Publications Ltd., London, GB; 

Class W01, AN 1997-326652 

XP002127385 

& JP 09 130476 A (NEC CORP), 
30 October 1995 (1995-10-30) 

* abstract * 



1,5,9,13 



1,5,9,13 



H0403/00 



TECHNICAL FIELDS 
SEARCHED (lnt.Cl.6) 



H04Q 
H04L 



The present search report has been drawn up for all claims 



Placa of search 


Gaia jf completion ot the search 


Examiner 


| THE HAGUE 


14 January 2000 


Strobeck, A 



CATEGORY OF CITED DOCUMENTS 

X . particularly relevant if taken alone 

Y . particularly relevant if combined with another 

document of the same category 
A . technological background 
O : non -written disclosure 
P ' intermediate document 



t theory or principle unde 'lying the rventon 
E ■ ranter patent document, but published cn, cr 

arte*- the tiling da:e 
D . dosumer; cited in the applicatton 
L : document cited lor o;her reasons 



& : member ot the same patent family, :orresponding 
document 



EP 0 912 069 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 

ON EUROPEAN PATENT APPLICATION NO. EP 98 40 2643 



This annex lists the patent family members relating to the patent documents cited in the above-mentioned Eurooean search report. 
The members are as contained in :he European Patent Office EOP tile on 

The European Patent Office is in no way liable for these particulars which are merely given for the purpose of information. 

"~ l 14-01-2000 



Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 


EP 0620693 


A 


19-10-1994 


GB 
JP 


2277423 A, B 
7015527 A 


26-10-1994 
17-01-1995 


JP 9130476 


A 


16-05-1997 


NONE 








3 
3 

i 



• ^ For more details about this annex : see Official Journal of the European Patent Office. No. 12/82 



BNSDOCID: <EP 091 206 9 A3 l_> 



i 



< j 



> 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 



£f~FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS " 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



BEST AVAILABLE IMAGES 




IMAGES ARE BEST AVAILABLE COPY. 



As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



This Pag© 



